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Abstract 

This document specifies the SyncML Device Management Protocol. This 
protocol is used to transfer management actions between the client and the 
management server. 
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1 Introduction 

This document describes a management protocol using the SyncML Representation 
Protocol [REPPRO]. This protocol is called the SyncML Device Management Protocol, 
abbreviated as SyncML DM Protocol, and it defines the protocol for various management 
procedures. 

2 Formatting Conventions 

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" and "OPTIONAL" 
in this document are to be interpreted as described in "Key words for use in RFCs to 
Indicate Requirement Levels" [RFC 2119]. 

Any reference to components of the DTD's or XML snippets are specified in this typeface. 

3 Terminology 

See SyncML Representation Protocol [REPPRO] and SyncML Synchronization Protocol 
[SYNCPRO] for definitions of SyncML terms used within this specification. 

See the DM Tree and Description document [DMTND] for definitions of terms related to the 
management tree. 

Full device URI 

Full path to a device resource specified in the device's context. It is always a URI 
relative to the devices' root node. Full device URI must always be used in the present 
specification. 

Message 

Atomic unit in SyncML DM Protocol protocol, one packet that the bearer network is able 
to accept. One SyncML DM Protocol package could be divided into many messages. 

Package 

Package is a conceptual set of commands that could be spread over multiple 
messages. 

Resource 

A network data object or service that can be identified by a URI, as defined in Section 
3.2 of Hypertext Transfer Protocol [RFC 2616]. Resources may be available in multiple 
representations (e.g. multiple languages, data formats, size, and resolutions) or vary in 
other ways. 
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4 SyncML Device Management Protocol Overview 

The SyncML Device Management Protocol allows management commands to be executed 
on nodes. It uses a package format similar to SyncML Synchronization Protocol 
[SYNCPRO] and SyncML Representation Protocol [REPPRO]. A node might reflect a set of 
configuration parameters for a device. Actions that can be taken against this node might 
include reading and setting parameter keys and values. Another node might be the run-time 
environment for software applications on a device. Actions that can be taken against this 
type of node might include installing, upgrading, or uninstalling software elements. 

Actions are represented by SyncML Device Management Protocol Commands, which are 
described in SyncML Representation Protocol, Device Management Usage [DMREPU]. 
The commands and message structure used correspond identically to that of the 
[SYNCPRO]. Thus, the DTD for the Management Protocol is the DTD from [SYNCPRO]. 

5 Node addressing 

Each node MUST be addressed by a unique full device URL URIs MUST follow 
requirements specified in Uniform Resource Identifiers (URI) [RFC 2396] with the 
restrictions as specified in [DMTND]. All URIs are case sensitive in SyncML DM Protocol. 
Node addressing is defined in SyncML Device Management Tree and Descriptions 
[DMTND]. 

Each node has a type that determines what kind of management content can be set/read 
on that object. Operations on a certain node require a predefined type of value to be sent 
and when the object is read, a value of that type is returned. For example a certain node 
can have a simple text type (text/plain) so simple text values can be set while another node 
stores complex types like the WAP Provisioning document type and require that value set in 
that node come with the WAP Provisioning document MIME type. Examples for other 
objects with complex values can be WAP settings or installed software. 

In SyncML DM Protocol, the target and source of a command are identified by the Target 
and Source elements respectively. Target refers to the recipient, and Source refers to 
the originator. Exceptions to this approach are mentioned in management commands 
requiring exception. 

6 Multiple Messages In Package 
6.1 Description 

The SyncML Device Management protocol provides. the functionality to transfer one 
SyncML package using multiple SyncML messages. This is necessary when one SyncML 
package is too large to be transferred in one SyncML message. For example, this limitation 
may be caused by the transport protocol or by the limitations of a small footprint device. 

In SyncML Device Management, the role of the package as a logical grouping of items is 
very limited. Most restrictions occur on messages, not on packages. For example, a 
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command must fit entirely into one message. This includes the Sequence and Atomic 
commands, each of which must fit entirely into one message. 

In order to avoid overwhelming a client with limited resources, a server is not permitted to 
send new commands to a client that has not yet returned a status to previous commands. 
In other words, most messages sent by the server to the client will correspond to a (one 
message) package, except in the case where a server is sending a large object or asking 
for more messages (using Alert 1222). A package containing a large object datum will 
span as many messages as necessary to transmit the large object, as specified in Section 
7. , 

Note that the server is always in one of the following states with respect to package 
boundaries: 

1 . The server has sent a complete package. In this state, the server is awaiting status from 
the client on the commands sent in the package. Because the status and results may be 
large, such as the result of Get commands, the client may send multiple messages back 
to the server before completing its response. 

2. The server has received a complete package (of responses) from the client. In this 
state, the server may send new commands to the client. 

3. The server has sent one or more messages that are part of the same package, but has 
not yet sent the final message of the current package. This state is only valid when the 
server is sending a large object, and the package will end when the last chunk of the 
large object is sent. 

Because the underlying transports for SyncML have a request/response form, either the 
client or the server may be required to send a message that contains neither new 
commands nor a Final flag, in order to keep the request/response cycle going. 

For example, when the server is in State 1 (above), it may receive many messages from 
the client containing status and results. The server will respond to each such message sent 
by the client, but may not include new commands in those responses. Messages sent by 
the server in this state will contain a status to the SyncHdr sent by the client, statuses to 
commands (Results) sent by the client, and also the Alert 1222 (More Messages). 

It is also possible for Alert 1222 to be replaced by Alert 1223 (Session Abort) if the 
server wishes to abort the session. 
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The following chart shows an example of how multiple messages can be used. 



DM Client 



DM Server 



Pkg #1: Alert 1201, Replace (Devlnfo), Final 



Pkg #2: Status on SyncHdr, Alert and Replace, Commands, Final 



Pkg #3 (1/2): Status on SyncHdrand commands, Results 



Pkg #4 (1/3): Status on SyncHdr and Results, Alert 1222 



Pkg #3 (2/2): Status on SyncHdrand Alert, Results, Final 



Pkg #4 (2/3): Status on SyncHdr and Results, Command containing Large Object 



Pkg #3 (1/2): Status on SyncHdrand commands, Alert 1222 



Pkg #4 (3/3): Status on SyncHdrand Alert, rest of Large Object, Final 



Pkg #3 (2/2): Status on SyncHdr and command, Results, Final 



Pkg #4: Status on SyncHdr and Results, Commands, Final 



Pkg #3: Status on SyncHdr and commands, Results, Final 



Pkg #4: Status on SyncHdr and Results, Final 



6.2 Requirements 

If a SyncML package is transferred in multiple SyncML messages, the last message in the 
package MUST include the Final element [REPPRO]. Other messages belonging to the 
package MUST NOT include the Final element. 

The Final element MUST NOT be supplied by the client to close its package until the 
server has sent its Final element to close the previous package. For instance, the client 
MUST NOT supply the Final element to close package #2 or package #4 until the server 
has supplied the Final element which closes the previous package (#1 or #3, 
respectively). This is necessary because packages #2 and #4 constitute replies to the 
commands in packages #1 and #3. 
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The recipient of a SyncML package containing multiple messages MUST be able to ask for 
more messages. This is done by sending an Alert command, with the alert code 1222, 
back to the sender. If there are SyncML commands to be sent as a response to a preceding 
message, i.e. Results, the Alert command with the 1222 alert code MAY be omitted. 

In the situation in which the server has sent the Final flag, and the client has not yet sent 
its Final flag, the server MUST respond to the client with the following "Next Message" 
response: 

The "Next Message" response contains Alert code 1222 (or 1223 to abort), status to the 
SyncHdr and to commands (Results), no other commands, and no Final flag. 

A server MUST send the Final flag in every message, when possible. This is not possible 
during the sending of a Large Object (see Section 7), or when sending the "Next Message" 
response. 

7 Large Object Handling 

In SyncML DM, large objects that do not fit within one message can be transferred by 
splitting the object across several messages according to the Large Object Handling 
specified in [SYNCPRO] Section 2.10, with the restrictions specified below. 

The first restriction is that clients that support Large Object Handling must indicate this by 
having the value of the DevDetail/LrgObj flag set to "true". The second restriction involves 
how the MaxObjSize is communicated between server and client (both directions). As in the 
Data Synchronization Protocol, MaxObjSize is communicated in Meta information. In the 
DM Protocol, the MaxObjSize accepted by the sender MAY be included in Meta information 
for the message header (SyncHdr) sent to the other party. MaxObjSize information sent in 
Meta information for the SyncHdr MUST be respected by the recipient, who MUST NOT 
send any single object larger than this size. If MaxObjSize is not sent, the recipient is free to 
send objects of any size back to the sender. 

Note that the MaxObjSize remains in effect for the entire DM session, unless a new value is 
supplied in a subsequent message. A possible reason to send a new MaxObjSize in a later 
message in the same session might be that the MaxObjSize of a client might depend on 
free memory, which can decrease as objects are created and increase as objects are 
deleted. The MaxObjSize need not be a dynamic quantity, however. 

8 SyncML DM Protocol packages 

SyncML DM Protocol consists of two parts: setup phase (authentication and device 
information exchange) and management phase. Management phase can be repeated as 
many times as the server wishes. Management sessions may start with Package 0 (the 
trigger). Trigger may be out-of-band depending on the environment and it is specified in 
SyncML Notification Initiated Session [DMNOTI]. 

The following chart depicts the two phases. 
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Client 



Package 0: alert from the server 



Package 1 : client initialization with client 
credentials and device information 



Server 



Package 2: server initialization with server 
credentials, initial management operations or 
user interaction commands from the server 



Setup phase 



Client Server 



Package 3: client response to server 
management operations 




Package 4: more user interaction and 
management operations if the session is 
continued. 


— ► 





Management phase 



The Management Phase consists of a number of protocol iterations 1 . The content of the 
package sent from the server to the client determines whether the session must be 
continued or not. If the server sends management operations in a package that need 
responses (status or Results) from the client, the management phase of the protocol 
continues with a new package from client to server containing the client's responses to 
those management operations. The response package from client starts a new protocol 
iteration. The server can send a new management operation package and therefore initiate 
a new protocol iteration as many times as it wishes. 

When a package from server to client does not contain management operations, the client 
will create a package containing only status for SyncHdr as a response to the package 
received from server. In this case the entire response package MUST NOT be sent and the 
protocol ends. A server MUST send response packages to all client packages. 

Processing of packages can consume unpredictable amount of time. Therefore the SyncML 
DM Protocol does not specify any timeouts between packages. 

If not otherwise stated by management commands, the client and server may freely choose 
the.execution order of the management commands sent in the package. However, when 
execution order is required by the parent management command, commands MUST be 
executed in the order they were sent. 



Protocol iteration means a package from client to server and a package from server to client. 
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Client MUST NOT send any commands other than Replace command containing Devlnfo, 
Results and Alert to the server. 

8.1 Session Abort 
8.1.1 Description 

Either the client or the server may decide to abort the session at any time. Reasons for 
session abort may be server shutdown, client power-down, user interaction on the client, 
etc. In this case it is best if the aborting party sends a SESSION ABORT Alert. It is 
recommended that the message also include status and Results of all the management 
commands that the aborting party executed before the abort operation. 

If a recipient of a Session Abort sends a response to this message, the response is ignored. 

Some cases of session aborts are not controllable, for example if the client goes out of 
coverage or its battery runs down. Servers and clients must be prepared for non-signalled 
session aborts as well. The requirements stated above are intended to reduce situations in 
which one party times out on a response from the other. 

Implementations are possible (e.g. OBEX) in which the request/response roles of the 
transport binding may be reversed, i.e. the SyncML Client is a transport-level server, and 
the SyncML Server is a transport-level client. In this case, the recommendation in Section 

8.1.1 above may not apply. 

8.1.2 Requirement 

Alert 1223 is used to signal an unexpected end to the device management session. The 
sender of the Session Abort alert MAY also include status and Results of all the 
management commands that the aborting party executed before the abort operation. A 
server receiving this alert SHOULD respond with a message that MUST contain status for 
the Alert and the SyncHdr and no new commands. 

A client receiving Alert 1223 SHOULD NOT respond. 

8.2 Package 0: Management Initiation Alert from server to client 

Many devices cannot continuously listen for connections from a management server. Other 
devices simply do not wish to "open a port" (i.e. accept connections) for security reasons. 
However, most devices can receive unsolicited messages, sometimes called "notifications". 

A management server can use this notification capability to cause the client to initiate a 
connection back to the management server. SyncML DM Protocol 1.1.1 specifies several 
Management Initiation notification bearers. Definition of bearers and notification content can 
be found from [DMNOTI] specification. 

Note that an identical effect to receiving a Management Initiation notification can be caused 
in other ways. For example, the user interface (Ul) of the device may allow the user to tell 
the client to initiate a management session. Alternatively, the management client might 
initiate a session as the result of a timer expiring. A fault of some type in the device could 
also cause the management client to initiate a session. 
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8.3 Package 1: Initialization from client to server 

The setup phase is virtually identical to that described in the [SYNCPRO], Section 4. The 
purpose of the initialization package sent by the client is: 



• To send the device information (like manufacturer, model etc) to a Device 
Management Server as specified [DMSTDOBJ]. Client MUST send device 
information in the first message of management session. 

• To identify the client to the server according to the rules specified in Section 9. 

• To inform the server whether the management session was initiated by the server 
(by sending a trigger in Package 0) or by the client (like end user selecting a menu 
item). 

The detailed requirements for the initialization package from the client to server (Package 
1) are: 

1 . The requirements for the elements within the SyncHdr element. 

• The value of the VerDTD element MUST be '1.1'. 



• The value of the VerProto element MUST be 'DM/1 . 1 

• SessioniD MUST be included to indicate the ID of the management session. If the 
client is responding to notification, with alert code SERVER-INITIATED MGMT 
(1200), then SessioniD MUST be same as in notification. Otherwise, the client 
generates a SessioniD which should be unique for that client. The same 
SessioniD MUST be used throughout the whole session. 

• MsgiD MUST be used to unambiguously identify the message belonging to the 
management session from server to client. 

• The Target element MUST be used to identify the target server. 

• The Source element MUST be used to identify the source device. 

• The Cred element MAY be included in the authentication message from the Device 
Management client to Device Management server as specified in Section 9. 

2. Alert MUST be sent whether the client or the server initiated the management session 
in the SyncBody. The requirement for the Alert command follows: 

• CmdlD is REQUIRED 



• The Data element is used to carry the management session type which can be 
either SERVER-INITIATED MGMT (1200) or CLIENT-INITIATED MGMT (1201) 
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3. The device information MUST be sent using the Replace command in the SyncBody. 
The requirement for the Replace command follows: 

• CmdID is REQUIRED. 

• An Item element per node found from device information tree. Possible nodes in 
device information tree are specified in [DMSTDOBJ]. 

• The Source element in the Item element MUST have a value indicating URI of 
node. 

• The Data element is used to carry the device information data. 

The Final element MUST be used in the SyncBody for the message, which is the last in 
this package. 

8.4 Package 2: Initialization from server to client 

The purpose of the initialization package sent by the server is to: 

• Identify the server to the client according to the rules specified in Section 9. 

• Optionally, the server can send user interaction commands. 

• Optionally to send management data and commands. 
Package 2 MAY close the management session. 

The detailed requirements for package 2 are: 

1 . The requirements for the elements within the SyncHdr element. 

• The value of the VerDTD element MUST be '1 . 1 '. 

• The value of the verProto element MUST be 'DM/1 .1 ' when complying with this 
specification. 

• SessioniD MUST be included to indicate the ID of the management session. 

• MsgiD MUST be used to unambiguously identify the message belonging to the 
management session from server to client. 

• The Target element MUST be used to identify the target device. 

• The Source element MUST be used to identify the source device. 

• Cred element MAY be included in the authentication message according to the rules 
described in Section 9. Server is always authenticated to the device but this 
authentication MAY be accomplished at the transport level. 
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2. The Status MUST be returned in the SyncBody for the SyncHdr and Alert 
command sent by the client. 

3. Any management operation including user interaction in the SyncML document (e.g. 
Alert, Sequence, Replace) are placed into the SyncBody. 

• CmdlD is REQUIRED. 

• Source MUST be used if URI is needed to further address the source dataset. 

• Target MUST be used if URI is needed to further address the target dataset. 

• The Data element inside item is used to include the data itself unless the command 
does not require a Data element. 

• The Met a element inside an operation or inside an item MUST be used when the 
Type or Format are not the default values. 

4. The Final element MUST be used in the SyncBody for the message, which is the last 
in this package. 

8.5 Package 3: Client response sent to server 

The content of package 3 is: 

• Results of management actions sent from server to client 

• Results of user interaction commands 

This package is sent by the client if Package 2 contained management commands that 
required a response from the client. 

The detailed requirements for package 3 are: 

1 . The requirements for the elements within the SyncHdr element. 

• The value of the VerDTD element MUST be 

• The value of the Ver Proto element MUST be 'DM/1 . 1 '. 

• SessioniD MUST be included to indicate the ID of the management session. 

• MsgiD MUST be used to unambiguously identify the message belonging to the 
management session from server to client. 

• The Target element MUST be used to identify the target device. 

• The Source element MUST be used to identify the source device. 
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• A status MUST be returned to indicate whether the authentication of device 
management server was successful or not. The CmdRef used in this status 
element MUST be SyncHdr. 

2. status MUST be returned for the SyncHdr and Alert command sent by the device 
management server in the SyncBody. 

3. status MUST be returned in the SyncBody for management operations sent by the 
server in Package 2. 

4. Results MUST be returned in the SyncBody for successful Get operations sent by the 
server in the previous package and the following requirements apply: 

• Results MUST contain Meta element with Type and Format elements describing 
content of Data element, unless the Type and Format have the default values. 

• Items in Results MUST contain the Source element that specifies the source URI. 

The Final element MUST be used in the SyncBody for the message, which is the last in 
this package. 

8.6 Package 4: Further server management operations 

Package 4 is used to close the management session. If the server sends any operation in 
Package 4 that needs response from the client, the protocol restarts from Package 3 with a 
new protocol iteration. 

The detailed requirements for package 4 are: 

1 . The requirements for the elements within the SyncHdr element. 

• The value of the verDTD element MUST be '1.1'. 

• The value of the verProto element MUST be 'DM/1.1'. 

• SessioniD MUST be included to indicate the ID of the management session. 

• MsgiD MUST be used to unambiguously identify the message belonging to the 
management session from server to client. 

• The Target element MUST be used to identify the target device. 

• The Source element MUST be used to identify the source device. 

2. status MUST be returned for the SyncHdr sent by the device management server in 
the SyncBody. 

3. Any management operation including user interaction in the SyncML document (e.g. 
Alert, Sequence, Replace) placed into the SyncBody. 
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• CmdlD is REQUIRED. 

• Source MUST be used if URI is needed to further address the source dataset. 

• Target MUST be used if URI is needed to further address the target dataset. 

• The Data element inside item is used to include the data itself unless the command 
does not require a Data element. 

• The Meta element inside an operation or inside an item MUST be used when the 
Type or Format are not the default values. 

The Final element MUST be used in the SyncBody for the message, which is the last in 
this package. 

9 Authentication 

SyncML DM Protocol uses the SyncML authentication framework, with extensions defined 
in SyncML Device Management Security [DMSEC]. This section specifies the rules how the 
SyncML-level and the transport-level authentication are used. 

Both SyncML DM Protocol client and server MUST be authenticated to each other. 
Authentication can be performed at different levels, however. If the transport level has built- 
in authentication mechanism then SyncML DM Protocol-level authentication MAY NOT be 
used. If the transport level does not have sufficiently strong authentication feature, SyncML 
DM Protocol-level authentication MUST be used. Server and client can both challenge each 
other if no credentials were given in the original request or the credentials were considered 
too weak. 

It is assumed that SyncML DM Protocol will often be used on top of a transport protocol that 
offers session-level authentication so that authentication credentials are exchanged only at 
the beginning of the session (like in TLS or WTLS). If the transport level is not able to 
provide session authentication, however, each request MUST be authenticated. 

The preferred authentication type of the server may be indicated to the client using the 
DMAcc/x/AuthPref parameter [DMSTDOBJ]. 

Generation and maintenance of client and server credentials are out of scope of the 
SyncML DM Protocol specification. 



10 User interaction commands 
10.1 Introduction 

The SyncML Device Management Protocol specifies following user interaction types for 
example to notify and obtain confirmation from the user regarding the management 
operation. These interaction types are the following: 
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• User displayable notification associated with a certain action. 

• Confirmation from the user to execute a certain management operation. 

• Prompt user to provide input for upcoming management operation. 

• Prompt user to select item or items among items. 

• Display progress notification for a certain action. 




10.2 User interaction alert types 

These Alert's can be sent only from the server to the client. If sent by the client, they are 
ignored by the server. Multiple user interaction Alert's can be present in Package 2, in this 
case the client executes them by arbitrary order (unless Sequence is used) and sends 
back the results in multiple status packages in Package 3. If the protocol continues after 
Package 4, Package 4 can also contain user interaction Alert's. 

When a user interaction is executed, server is notified about the outcome of the interaction 
in a status message. The user interaction-specific status responses are described in 
[DMREPU]. 

All user interaction Alert's contain two or more item elements. Client MUST preserve the 
order of these item elements. Client MUST also process these item elements in the same 
order as they are in the message. 

User interactions, except display, SHOULD have user option to cancel operation. If the user 
decides to cancel the operation, then management message processing is stopped. Status 
codes for executed commands are reported normally and status code ( 2 1 5 ) No t 
executed is returned to all commands which are not processed. After processing the user 
response the server might decide to continue protocol with some other management 
operation. 

If the Ul allows the user to cancel (for any of the Ul Alerts), then the status (214) 
Operation cancelled should be returned for the Alert. 



10.2.1 Display 

The SyncML DISPLAY Alert is slightly changed in SyncML DM Protocol. The Alert has 
two Items. 

• The first item contains optional parameters as specified in Section 10.3. 

• The second item has exactly one Data element containing the text to be displayed to 
the user. 
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Example: 



< Alert > 










<CmdID>2</CmdID> 










• <Data>1100</Data> 










<Item><Data>MINDT=10</Data></Item> 










<Item> . .> .]■ 










:W < Da t a >Management in progress</Data> 


::^:: ::' 




WSM. ■' f! 


« : : 


</Item> 










< /Alert > 











10.2.2 Confirmation 

Confirmation is a binary decision: the user either approves or rejects the option. A new 
Alert type is introduced for this purpose, the CONFIRM_OR_REJECT. When the client 
receives this Alert, it displays the Alert text then enables the user to select "Yes" or 
"No". If the answer is "Yes", the processing of the package continues without change in 
processing. If the Ul allows the user to cancel, status (214) should be returned for the 
Alert. 

If user answers "No", then package processing will change according to placement of 
confirmation Alert in package as follows. 

• If confirmation Alert is inside Atomic, then Atomic fails and all executed commands 
have to be rolled back. 

• If confirmation Alert is inside Sequence, then commands in Sequence after 
confirmation Alert are bypassed. 

• If confirmation Alert is not inside Atomic or Sequence i.e. it's directly in SyncBody, 
then user response has no effect to package processing. In this way server can query 
user opinion before sending actual management commands to client device. 

Status code (215) Not Executed will be sent back for the commands whose execution 
was bypassed as result of user interaction. 

The Alert contains two item's. 

• The first item contains the optional parameters as specified in Section 10.3. 

• The second item has exactly one Data element containing the text to be displayed to 
the user. 

Example: 



<Alert> ^ : :i \; - 

<CmdID>2</CmdID> 
<Data>1101</Data> 

<Itemx/Item> <!— no optional parameters 



<Data>Do you want to add the CNN access point?</Data> 
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</Item> 
</Alert> 1 



Result if user responds "No": 



<Status> , • . , 4< . ^ . & • k if* • ; > x # : 



<CmdID>2</CmdID> 
<MsgRef >l</MsgRef > 
< CmdRe f > 2 < / CmdRe f > 

<Cmd>Alert</Cmd# - 4 " : - - : " s 

<Data>304</Daf < ! - - |Npt : modified - > : ; : , :i| 

:/Status> .. . . : . 



r ;, : ■ . : • ■ : r •>§? : f- ; r*- 



If the result in the above example had been that the user chose Yes, the status would have 
been (200). 

10.2.3 User input 

When this Alert is sent, the client displays the text then allows the user to type in a text 
string. This text string is then sent back to the server in a status message. 

The server instructs the client to execute this user interaction by sending a TEXT INPUT 
Alert. The Alert contains at least two item's. 

• The first item contains optional parameters as specified in Section 10.3. 

• The second item has exactly one Data element containing the text to be displayed to 
the user. 

Example: 



<CmdID>2</CmdID> \ "■ 

<Data>1102</Data> - V 1 :% 

<Item>:<:/Item> v . . .'. \--\ \ ■ }]y: \i y . \\\\-\-\ . 

<Item> < " 

<Data>Type ^ in the name „ of ^the^. service you „would like to 
conf igure</Data> 



</Item> 
< /Alert > 



i f • - 1 



The user is presented with the text and an input box to type in the message. The following 
status message is sent back in the next message from client to server: 

<Status> . 

<MsgRef >l</MsgRef > : 

<CmdRef >2</ CmdRe f> . \ 
<Cmd>Alert</Cmd> j 
<Data>200</Data> <!-- Successful, user typed in a . text -•-> ... 
<Item> 

. <Data>CNN</Data> ;.< ! -- User input 

</Item> : . " : ] 

</Status> .: ;: . • = • :: . - 
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10.2.4 User choice 

When this Alert is sent, the user is presented with a set of possible choices. The Alert 
body MUST contain the following item's. 

• The first item contains optional parameters as specified in Section 10.3. 

• The second item has exactly one Data element containing the title of the selection as . 
plain text. 

• From third item onwards the Item contains exactly one Data element that describes 
one possible choice as plain text. These item's are referenced by a number starting 
from 1. item's MUST be numbered in the order they were sent, item's SHOULD be 
presented to the user in the order they were sent. 

The user selection is returned in status message. The selected item is returned in an 
item. The Data element of this item contains the reference number of item. A variation of 
this Alert allows the user to select multiple items. In this case selected items are sent 
back in multiple item's in the same way as one selected item. 

One possible implementation could be a list and each Data member of the Alert could be 
displayed as a row in the list. The user could select a list item then he or she would push 
the "Ok" button and the ID of the selected list item is sent back in a status message. 



Example for a single-choice Alert: 



<Alert> 






<CmdID>2.</CmdID> $ ■■ ... • : 






<Data>1103</Data> ..: 






<Item><Data>MDT=ld</Datax/ltem> 






<Item> ' : i • 






<Data>Select service to configure < /.Data > 






</Item> ; 






<Item> ' - : s ■ 






■y\'r <Data>CNN</Data> y\:::. { -\: 






</Item> : ; - j !:^?L 






:<Item> m.^- ■ .. ^-i- ■ 






<Data>Mobilbank«/Data> : If • 






■ </Item> ' ' • 






:■■ <ltem>: ],%.]. . 






<Data>Game Channe 1 < /Dat a > ; : . 






</ltem> . . yy 
</Alert> 


ymk,y ^ 





Response to this Alert returns the selected item. 



< Status > .:i .;•'. :!• '. 
■ " r i : :<MsgRe f > I < /MsgRe f > 
i <CmdRef >2</CmdRef > 
<Cmd>Alert</Cmd> 
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<Data>200</Data> < '--Successful, user selected an item --> 
<Item> ;. : ; : ' ^ ; : ::... ; ; ■ • ; ; & [ \ : . : ':\ • : ' ' ; : i : ' ' . : • ' '. ■ ■ ' ■■ ' . W' i:i \ ' • • ' ■ 

<Data>2</Data> <!— User selected Mobi IBank --> 
</Item> 
</Status> 



Example to multiple-choice Alert 



<Alert> 



; <CmdID>2</CmdID> : ■ . /vX <;: ■ ; , . : . -p.. 

<Data>1104</Data> ' ' " " % 

. <Item></Item> :/^-\- -^ :.: — -W : ' ■ 
<Item><Data>Select service to conf igure</Datax/ltem> 

• <Item> : : ; : | : • : : . ^ ' \ : 
<Data>CNN</Data> 

</Item> n ■ ' ' ' 

<Data>Mobilbank< /Data> ; ; : 



</Item> ; • 

<Item> : : .':R 

.: : 

<Data>Game Channel </ Da t a > 



</ltem> 
</Alert> 



■I- 



Response to this Alert returns the selected item. The number of the selected items can 
be returned in arbitrary order by the client. 

< Status*/ W. j;-pp; j'S ■; : |i| ;|ii/:. 1-^ | : : ; : : ; ; . . : : ; ; : ■ ; r . : r ; : : . ^ " ■ ; | i ; ; ^ | : i ^ : ; l. ; 

- <MsgRef >l</MsgRef > ' j. 

<CmdRef >2</CmdRef > 

<Cmd>Alert</Cmd> 

<Data>200</Data> < {-Successful, user selected an : item 
" <Item> : • ■ ' • : " • ' : . ' " : ' 

<Data>3</Data> 
</Item> 

, s<Item> ■: > • •« :; f ^ ' ' « ; ^ > "i:..;^: ? : >; ■ 

<Data>2</Data> <!— User selected Mobi Ibaiik and Game Channel --> 

: </item> ;| M'--- f : "* : ; : ' ^ : : " ' -\ r ;:::nt^- ; : 



10.2.5 Progress notification (object download) 

User SHOULD be able to track the progress of a longer management operation like a file or 
object download. SyncML Device Management Protocol will not provide a separate 
mechanism for progress notification but it will entirely reuse the SyncML size Meta- 
Information tag defined in SyncML Meta-lnformation DTD [METINF] and will make a 
recommendation for device manufacturers to use this tag for displaying progress 
notification. 

According to SyncML Meta-lnformation DTD, any item can be tagged by size meta- 
information that determines the size of the object. When the device encounters a size 



Copyright © 2002 Ericsson, IBM, Lotus, Matsushita Communication Industrial Co., Ltd., 
Motorola, Nokia, Openwave, Palm, Psion, Starfish Software, Symbian and others. All Rights Reserved. 




SyncML Device Management Protocol 
http://www.svncml.org/docs/svncml dm protocol v1 11 20021002.pdf 



23 of 23 Pages 
Version 1.1.1 
2002-10-02 



meta-information tag in a received item, it MAY display a progress notification on the user 
interface if the device decides that the item with the given size will take a longer time to 
download. The progress notification bar is scaled according to the length information 
conveyed in the Size element. If the size information is not sent by the server, the client is 
not able to display a scaled progress bar so it is recommended that servers send this 
information if the object to be downloaded by the client is reasonably large. 

Example of an antivirus data file download with size Meta Information. 



<Add> 

<CmdID>2</CmdID> 
: <Meta> 

' < Format xmlns= " syncml : metinf " >b64 < /Format > 
<Type xmlns="syncml:metinf" > 

application/ant ivirus - inc . virusdef 

m !,</Type> . M ] 4 

</Meta> - 

'i: <Ite M m> - - 4 J - . 

<!— Size of the data item to download --> 

<Size xmlns= ' syncml : metinf 1 >37214</Size> '■: 

</Meta> . ' WMm. m § 

< Targe t><LocURI> . /antivirus_data</LocURI></Target > 
<Data> ::.|; ■ -.^IS-M WS : . Ml 

< !—Base64- coded antivirus file; --> 

: (I </Data> ; p^ilir ll ; lllll-ll 

; ; </Item> t % 

</Add> ■- ■ , : ; ■■• % ;• |' || ; . . ; 



■ii-i ■\\m\ 



Progress indicator will be displayed during the execution of the Add command and it will be 
scaled so that the total length of data to be downloaded is supposed to be 37214 bytes. 

10.3 User interaction options 

Alert's MAY have optional User interaction parameters in the first item. Optional 
parameters are represented as one text string inside the Data element. If the User 
interaction Alert does not have optional parameters, the first item is empty. The optional 
parameter string conforms to the URL encoding format specified in [RFC 2396]. 

The following example uses two optional parameters: 

t MAXDT=30&DR=1 . .. . , „ | 



The client MUST skip without error message all the optional parameters that it is not able to 
process. 

For the moment following optional parameters are defined. 
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10.3.1 MINDT (Minimum Display Time) 

This parameter is a hint to the user agent, what is the minimum time that the user 
interaction should be displayed to the user. This can be important to guarantee that a 
notification message is readable. 

MINDT parameter MUST have a value that can be evaluated as a positive, integer number. 
Value of MINDT is interpreted as notification display time to user in seconds. 

Example: 

< l --Display this message for at least 10 seconds --> 
<Item><Data>MINDT=10</Data></ltem> 



10.3.2 MAXDT (Maximum Display Time) 

This parameter is a hint for the client, how long the client should wait for the user to execute 
the user interaction. If the user does not act within MAXDT time, the action is considered to 
be cancelled and a timeout status package or default response package is sent back to the 
server. 

MAXDT parameter MUST have a value that can be evaluated as a positive, integer 
number. Value of MAXDT is interpreted as seconds to wait for user action. 



Example: 



<}-- Wait maximum 20 seconds for the user --> 






<Item><Data>MAXDT=2 0</Datax/Item> 


: §p 'MM: t: ;i it; SH-i 


- ..: : ::i 



10.3.3 DR (Default Response) 

DR optional parameter specifies the initial state of the user interaction control widget. Other 
than setting the initial state of the user interaction control widget, DR has no other influence 
on the user interaction control widget. Interpretation for different user interaction types is the 
following: 

• If the user interaction is Notification, this optional parameter is ignored. 

• If the user interaction is a confirmation, 0 means that the reject user interface element is 
highlighted by default, 1 means that the accept user interface element is highlighted by 
default. Highlighted user interface element means that the "default" user interaction (like 
pressing Enter button) will select the highlighted user interface element. If the client user 
interface has no notion of highlighted user interface element, this parameter MAY be 
ignored; 

• If the user interaction is user input, DR value specifies the original text in the text input 
user interface element. This text MUST conform to the optional parameter syntax rules. 

• If the user interaction is single-choice, the DR value is the originally highlighted choice 
item, item e.g. value between 1 and the number of items in the selection list. 
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• If the user interaction is a multi-choice, the DR value is a minus sign-separated list of 
originally highlighted values (for example: 2-3). 

Examples: 



< ! — Accept by default in: a Confirmation action 
<Item><Data>DR=l</Datax/Item> : ;i : r : 



<;,! - - Default userientry of "John Doe." inian Aiser^iriput iaction --> :: : ]' 

< I tem><bat a >DR= John+Doe< /Data >< / 1 1 em> ; • -■• t Y W 



<!-- Default selection of item 3 in a single-choice action - -> 
<Item><Data>DR=3</Datax/Item> 



< ! - - Default selection of item 2 and 3 in a mult i -choice action --> 
<ItemxData>DR=2-3</Datax/Item> 



10.3.4 MAXLEN (Maximum length of user input) 

MAXLEN value is evaluated to a positive integer and determines the maximum number of 
characters that can be typed into the text input user interaction widget. The optional 
parameter MUST be ignored in all other kind of user interaction widget. If the specified 
maximum length of input string exceeds the capability of the client, the client MAY ignore 
the parameter. 

Example: 

<!-- Maximum string length is 30;— > 
<ItemxData>MAXLEN=30</Datax/ltem> 



10-3.5 IT (Input Type) 

IT specifies what kind of characters are allowed in the text input user interaction widget. 
Based on this information a client with limited keyboard MAY display user interaction 
elements that allow easy input of characters not present on the keyboard. The optional 
parameter MUST be ignored in user interaction widgets other than text input. Allowed 
values: 

IT=A - Alphanumeric input, client SHOULD allow input of all alphanumeric characters. This 
is the default behaviour. 

IT=N - Numeric input, client SHOULD allow input of all numeric characters, decimal point 
and sign character. 

IT=D - Date input, client SHOULD allow input of all numeric characters. User input is 
delivered to server in following text string format "DDMMYYYY", where; 
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• DD is day with possible leading zero. 

• MM is month with possible leading zero 

• YYYY is year presented with four digits 

IT=T - Time input, client SHOULD allow input of all numeric characters. User input is 
delivered to server in following text string format "hhmmss", where; 

• hh is hours with possible leading zero. 

• mm is minutes with possible leading zero. 

• ss is seconds with possible leading zero. 

IT=P - Phone number input, client SHOULD allow input of all numeric characters, "+", "p", 
"w" and "s". "+" MUST be first if present in phone number. 

IT=I - IP address input, client SHOULD allow input of all numeric characters. User input is 
delivered to server in following text string format "xxx.yyy.zzz.www" 



Example: 



<!-,-: Numeric text input. -->. - ^ % 
<Item><Data>IT=N</Data>.</ltem>. . .: i • 






J .y : .:r:::;x:. - :.: 

■ ■ . y :i <■■',: -;f.; 


status message delivered to server as response 


<Status> 

<MsgRef >l</MsgRef> 
: < CmdRe f > 2 < / CmdRe f > 
; < Cmd > Al e r t < / Cmd > 

<Data>2 00</Data> < ! - Successful, entered a number - -> 
<Item> '■ ■ ■ 

<Data>-l . 23</Data> 
</Item> 

< /Status > : ... :t -::y- 


■ ; :; : \. \--.\ 

■ \ : ! - ■ '■ ' ' ' \ - 




SyncML I 



10.3.6 ET (Echo Type) 

ET specifies how text input user interaction widget echoes the characters that the user 
types in. The optional parameter MUST be ignored in user interaction widgets other than 
text input. Allowed values: 

ET=T - Text input. The client SHOULD allow the user to see the character the user typed 
into the text input user interaction widget. This is the default behaviour. 

ET=P - Password input. The client SHOULD hide the character the user typed into the text 
input user interaction widget. One way of doing it MAY be writing an asterisk instead of the 
character itself. 

Example: 
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<! — Numeric text input --> 
<Item><Data>ET=T</Data></Item> 



11 Static conformance requirements 

Conformance requirements for SyncML Device Management Protocol are defined in 
SyncML Device Management Conformance Requirements [DMCONF]. 
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rDMREPUl SyncML Representation Protocol, Device Management Usage, version 
1.1.1, SyncML. 

rDMNOTIl SyncML Notification Initiated Session, version 1.1.1, SyncML . 

[DMTND1 SyncML Device Management Tree and Descriptions, version 1.1.1, 
SyncML . 

rDMSTDOBJI SyncML Device Management Standardised Objects, version 1.1.1, 
SyncML . 



fDMCONFl 

fDMSECl SyncML Pevice Management Security, version 1.1.1, SyncML 



SyncML Pevice Management Conformance Requirements, version 1.1.1, 
SyncML . 
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13 Appendices 
13.1 Protocol Values 



VerProto Codes 


Description 


DM/1.1 


Indicates that this SyncML message uses 
the SyncML Device Management Protocol 
defined by the SyncML Initiative. 
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14 Protocol examples 

In this section several protocol scenarios will be demonstrated. 
14.1 One-step protocol initiated by the server 

In this section an example is presented when a WAP connectivity context is added to the 
WAP settings. The user is asked a confirmation whether the settings could be added. 

14.1.1 Package 1 : Initialization from client to server 



< SyncML xmlns= ' SYNCML : SYNCML 1 . 1 ' > 
; <SyncHdr> 

:•: <VerDTD>l . l</VerDTD> 

<VerProto>DM/l . !</VerProto> 
<SessionID>l</SessionID> 
<MsgID>l</MsgID> 
<Target> 

<LocURI>http: //www. syncml >6rg/mgmt- server < /LocURI > 
< /Target > 

< Source > . l : ^ - 

<LocURI>IMEI:493005100592800</LocURI> 'j 
. </Source5| < . -.g . . -i ■ : |r' : ' 

<Cred> < {•-- Client credentials are mandatory if the transport layer 
not providing authentication. .. 

T <Meta> .... . . ■ j: '. : : -;^i::-.j- r ;;i ; M ; £ f : : : : ; 

<Type ! xmlns= u syncml : met infr>syncml :auth-basic</Type> * 
< Format xmlns= 'syncml rmetinf ' >b64< /Format > 



is 



</Meta> : 

<Data> • , v.. ■■■■ ... 

<!— base64 formatting of userid: password --> 
</Data> 

</Cred> ^ . . • : ' 

<Heta> < ! - - Maximum message size for the dient — > 

.<MaxMsgSize xmlns= "syncml rmetinf M >50.00</MaxMsgSize> 
</Meta> - ; 
</SyncHdr> 

<SyncBody> ' .' 4 . • ■> 

<Alert> 

> <CmdID>l</CmdID> 'I ' 

<Data>1200</Data> <!- -Server-initiated session --> 

, „ _ :: • • ' .y .... . a-; / . -'A-'- " . : : ,' : " .' .. • . ^ ■ 

</Alert> ' ■ : ■ 

<Replace> ; ^ ' 

<CmdID>3</CmdID> \ 
. . <Item> 

<Source><LocURI > . /Devlnf o/DevId< /LocURI >< /Source> 

; <Meta> . . ly/: ,:y, . ' [/^M t^, >§; aa0[-M< 

< Format xmlns= ' syncml rmetinf 1 >chr< /Format > 
<Type xmlns= ' syncml rmetinf ' >text/plain</Type> : 
</Meta> " : 

< Dat a >4 930051 00 5 92 80 0 < /Dat a > : i; \.l ' "4 ■ 

</Item> . • ' 

: ■■'k'.' '■ '.\ <Item> ' :^<:.Mm\ " \. Life: M M : !- : H : Ll-f i-Jj-^l ^ L'hhH- i:i N-^4:M b^Sh:i 
<SourcexLocURI> . /Devlnf o/Man< /LocURI >< /Source > 
<Meta> 

; < Format xmlns= ' syncml rmetinf >chr</ Format > : 
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<Type xmlns= 1 syncml : met inf 1 >text /pi a in</ Type > 
</Meta> ' •;. • -« • ;V; : ; :. ■ ;. 

<Data>Device Factory, Inc. </Data> 

</Item> 

<Item> 

f <SourcexLocURI> . /Devlnf o/Mod</L6cURI></Source> 

:| <Meta> . • : :\. ! J.f r^"H ! ! ; : ^J 

< Format xmlns= ' syncml : met inf 1 >chr< /Format > 
<Type xmlns= ' syncml : met inf 1 >text/plain< /Type > 0 
|'| </Meta> " • i :; :: : -S 

<Data>SmartPhone2000</Data> 
i</ltem> . : ^: -r,- \:.:.\, ; . . W.---: : 

<Item> ■ ■ c '\' . ' - '• 

iil; <Source><LoctJRI> . /Devlnf o/DmV</LocURI></Source> 
■ <Meta> ^ ; ^ 

< Format xmlns4 ! syncml : met inf r >chr<: /Format > : - 
< Type ,xmlns=Vsyncml : met inf ' >text/plain</Type> 
</Meta> ' 

<Data>l .0 . 0 . 1</Data> 
</ltem> '' :w: ^'W ^f r --\1:: ' : : - ■' " £ 



<Item> 



<Source><LocURI> . /Devlnf o/Lang</LocURIx/Source> 
V <Meta> :: ' ;: ■ ' .:; 

< Format xmlns= ' syncml : met inf ' >chr</ Format > 
:<Type xmlns= ' syncml : met inf ' > text /plain</Type> 1 



</Meta> 
<Data>US-en</Data> H*: . 



</ltem> 
</Replace> 
: <Final/> : : 
</SyncBody> ; J. : : 

</ SyncML > : ; r 



14.1.2 Package 2: Initialization from server to client 



< SyncML xmlns== ' SYNCML : SYNCML 1 . 1 ' > ... \ 
; <SyncHdr> 

<VerDTD>l . !<:/VerDTD> H \ ' >: 

<VerProto>DM/l . l</VerProto> '' 
<Ses S ionID>K/Se S sion I D> : 
: . <MsgID>l</MsgID> r f! : i::^i--" 

. ' <Source> ' • ' ' : 

;; <LocURI>http: / /www , syncml . org/mgmt- server </LocURI> ; 
</Source> 
[■ .< Target > ? 

<LocURI>IMEI:493005100592800</LocURI> 
</Target> 

: <Cred> < !^Server credentials : \;H;ir:;-i:;; ; - : vhi;;;i ; ; 

: . :;<Meta> : : : ; : ;^ : ^'W-.-.-.:-.'.-- .i.\W:\ ■'■■'■y.. 

:. v <Type xmlns="syncml : met inf "> syncml :auth-basic</Type> 
..•< Format xmlns= • syncml : met inf • >b64< /Format > 

</Meta> : \ ; 

<Data>< ! — base64 formatting of userid: password --><;/Data> ; 
</Cred> : . y ; W:' : ''\Mi 

</SyncHdr> ■ ; . ; l i = ; 

■ < Sync Body > " : ; ; T ; ; . - ; ; ^ ^ . : . -:.:\ . 

i <Status> i ; ' ■ ■ ■ : 
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: k 

'Mi 



<MsgRef >l</MsgRef xCmdRef >0</CmdRef > 
■ :: '<Cmd>SyncHdr</Cmd>, y:: i:;.::!^^^: 
<CmdID>6</CmdID> ■ 

< Targe tRef >http : / / www .syncml . org/mgmt - server < /Targe tRef > 
: <SourceRef >IMEI : 493005100592800</SourceRef > : : 
- <!— Authenticated for the session --> 

<Data>212</Data> : 
</Status> 

<Status> •. ■ : ■ . : ; 

< MsgRe f > 1</ MsgRe fx CmdRe f > 1 </ CmdRe f > 
<CmdID>7</CmdID> 

. < Cmd > A 1 e r t < / Cmd > ■ 
; <Data>20d</Data>< !— OK — > 
■ </Status> :. ^ ; . 
: <Status> v \: ■ ■ 

< MsgRe f>l< /MsgRe fx CmdRe f >3</ CmdRe f > 
<CmdID>8</CmdID> ; ;||| 
<Cmd>Replace</Cmd> 
<Data>2 00</bata>< ! - - OK - - >■ 

</Status> 

<Sequehce> v'Mh^.W iHIS 

<CmdID>l</CmdID> 
fl <Alert>! ; I 

:<CmdID>2</CmdID> 

<Data>1101</Data> < ! - - User confirmation required 
<Itemx/Item> 

<IteiTl> : ' : $ '■ ■■ 

<Data>Do you want to add the CNN access ;point?</Data^ : :f 
l \ ; ; . . ; </ Item> ; \ %\ \ % ; : ; : : ; ; . ; ; ; ;j| : : ; . 
< /Alert > 



<Replace> 

<CmdID>4</CmdID> 
: <Meta> -'\ : y. : 

< Format :xmlns=" syncml imetinf " >b64</Format> 
: : <Type xmlns =" syncml: met inf " > 
; i appl icat ion/vnd . wap . connectivity-wbxml 
</Type> 

. ■ </Meta> '.■ i jjil:;::;' . 

t : CNN WAP settings object in the settings' -- -> • 



: <Target> . . ■ ;■; " :/ . ' ' ' ^ : 

<LocURI> . /settings/wapvsettings/CNN</LocURI> 
< /Target > 

: < Da tax ! Base64-coded WAP connectivity document - - >< /Data> 

</ltem> 

</Repiace> : : \L'-'-W':\\. .''J:: : '\ ■■ ?; 

f </ Sequence > 
: < Final/ > •;; 
</ Sync Body > 
< /SyncML > 



14.1.3 Package 3: Client response 



<SyncML xmlns=' SYNCML : SYNCML 1 .1' > 
<SyncHdr> 

% < Ve r DTD > 1 . 1 < /Ve r DTD > 
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<VerProto>DM/l. l</VerProto> 
<SessionID>l</SessionID> : 
: : <MsgID>2</MsgID> . ' '-''-X •:: X/X^^X 

<Target> ; : . . 

• ;::i:<LocURI>http i //www. syncml . org/mgmt - server< /LocURI > 
</Target> •:! : -X\ \\-A\ : . ; : ■' . - X :: X ;; : 

<Source> 

' <LocURI>IMEI:493005100592800</LocURI> 
</Source> : 
</SyncHdr> 
<SyncBody> 

<Status> ; . 

<MsgRef >l</MsgRef > . 

:<CmdID>l</CmdID> ; ; 
: <CmdRef >0</CmdRef > X y-:X..xM.\fMW-- 

<Cmd>SyncHdr</Cmd> 

<!-SyhcHdr accepted '-->. 
: <Data>212</Data> X 
< /Status > 

<Status> / ; 

<MsgRef >l</MsgRef > 
<CmdID>2</CmdID> 
X <CmdRef >l</CmdRef > ' 

<Cmd>Sequence</Cmd> 
;;: < !— Sequence executed correctly --> ; . ; ' • .. 
; <Data>200</Data> 
|v- .</Status> : 



<Status> : 

< MsgRe f > 1 < / Ms gRef >,< CmdRe f > 2 < / CmdRe f > 

; < Cmd I D > 3 < / Cmdl D > ftf| : .i: 'iirii^^-p:^;;^:. 

< Cmd > Al e r t < / Cmd > 

<!-OK; the user confirmed the; action- -> 
<Data>2 00</Data> 
< /Statu| > 
; <Status> 

<MsgRef >!</MsgRef > 
< CmdRe f>4</CmdRef> 
<CmdID>4</GmdID> ; :■; 
■ <Cmd>Replace</Cmd> i 

<TargetRef>. / sett ings / wap_set t ings /CNN< /TargetRef > 
< !— OK, access point added- -> 
<Data>200</Data> 
< /Status > X'A\XXXXi XXr ■:■ 

X, <Final/> : xXM-^'X ' : X'X'--X XXX . . ... XXXXi XM[XM. 

L </SyncBody> : " h X ': ' '' 

</SyncML> jh X ' ■ : - XX^ ■; ■ X 



X-X y 



14.1.4 Package 4: Acknowledgement of client status 



This package is now empty as no actions are sent and client does not continue the 
protocol. 



| <SyncML xmlns= ' SYNCML : SYNCML 1 . 1 ' 7" 
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<SyncHdr> . : ; 

<VerDTD>l . l</VerDTD> 

<VerProto>DM/l . l</VerProto> ■ . >; 
<SessionID>l</SessionID> 

<MsgID>2</MsgID> . ■. \ : ' ; 

<Source> 

<LocURI>http: //www. syncml .org/mgmt-server</LocURI: 
</Source> : ■ f : : ? " 

<Target> " - : 

<LOCURI>IMEI:493005100592800</LOCURI> i;: 
< /Target > • 



</SyncHdr> 
<SyncBody> 
<Status> . 

<MsgRef >2</MsgRef > 
: <CmdID>l</CmdID> 
< CmdRe f > 0 < / CmdR e f > 
<Cmd>SyncHdr</Cmd> 
<Data>2 00</Data> 
</Status> 
■-■]:.:'\ y <Final/> •;; : -| ; ;; : 
: </ Sync Body > 
< /SyncML > f ... 



/J f$!':. 



-Hill 



•::•:;•;•>.•:. 



14.2 Two-step protocol initiated by the server 

Operator initiates a regular antivirus software update on PDA clients. The server checks the 
installed version in the first management section then updates the antivirus data in the 
second step. 

14.2.1 Package 1: Initialization from client to server 



< SyncML xmlns= ' SYNCML : SYNCML 1 . 1 ' > 
\ <SyncHdr> 

■ i : <VerDTD> 1 . 1 < / VerDTD> 

<VerProto>DM/l . l</VerProto> : 
<SessionID>l</SessionID> 
i: <MsgID>l</MsgID> , 
<Target> 



|i,r r..p: 



W0B 



1 </^S^ >httP: //WWW * SynCm1 ^ org^mgm^-server^LocUR^ 



<Source> 

<LocURI>IMEI : 493 0051005928 00</LOCURI>; : 



;i: </Source> 'i-i'^L- 
*■ <Cred><! -Client credentials are optional --> 
<Meta> : ; :: !;:V.;;:: 

<Type xmlns - " syncml : met inf ">syncml : auth-bas i c< /Type > 
<Format xmlns= 'syncml rmetinf ' >b64< /Format > 
</Meta>^ ; ^ -^ife^^.' ■■: % 

<Data>< !-- base64 formatting of userid: password --></Data> 
</Cred>. 

<Meta>< !-- Maximum message size for the client -->. 

;<MaxMsgSi2eixmlns= "syncml : met inf M >5000</MaxMsgSize> 
</Meta> . - . 

</SyncHdr> 
. <SyncBody> ii; 



• -v. ■ 
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' <Alert> 

< Cmdl D > 1 < / Cmdl D > 

<Data>1200</Data> < ! - - Server-initiated session — > 
</Alert> 

<Replace> [ 
. <CmdID>3</CmdID> :\].- .^'V- ;| ;.:.v .•• ■ - 

. <Item> ; ! j ; i ; L i ; IU ^ 1 1 e E ^- : i .e. : !-! U ! ! ^ . . t iSil E U"^K ^ > H e e i - : 

_ i: < Source xLqcURI > i /DevInfo/DevId</LocURIx/Source> 
:::::<Meta>: : i: : ;;i : ;::.:; ; i: :: : M \: 

: < Format xmlns= ! syncml: me tirif * >chr</ Format > ; 
j; <Type xmlns= 1 syncml imetinf >text/plain</Type> 
</Meta> : ... 
: <Data>493005100592800</Data> 
</Item> : 
I <Item> ; ■ |j: 

<Source><LocURI> . /Devlnf o/Man</LocURI></s6urce> 

: < Format ; xmlns= 1 syncml imetinf 1 >chr</Format> 



<Type xmlns= ' syncml : met inf 1 >text/plain</Type> : 
<Data>Device Factory, Inc. </Data> 



</Meta> 



•^<:/Item> ;;);.; • • ;;: : :!;:;^: ; 

<Item> : 

<Source><LocURI> . /Devlnf o/Mod</LocURI >< /Source > 



<Meta> : : • . ' : . • 

• ; < Format xmlns= 1 syncml imetinf ' >chr< /Format > 



<Type;|xmlns= ' syncml : met inf ' >text/plain</Type> 
i </Meta> v|; ' 

< Da t a > Sma r t Phone 2 0 0 0 < / Da t a > 
. </Item> 

<Item> 

<SourcexLocURI> . /Devlnf o/DmV</LocURIx/S6urce> 
<Meta> ' 
< Format xmlns= ' syncml : met inf 1 >chr< / Format > 
<Type xmlns= 1 syncml imetinf ' >text/plaih</Type>;; 
</Meta> 

<Data>1.0.0.1</Data> 
</ltem> 

1; <Item> ;jl ' 

< Sour ce xLocURI > • /Devlnf o/Lang< /LocURI x/ Source > 
■■\ ' \\\ '% <Meta> / ':■ ^liP-^:!:-!:-;:;:';^;' 

<Format ; xmlns= 1 syncml imetinf ; ! >chr</Format> 
<Type xmlns= ' syncml imetinf 1 >text/plain</Type> 
:::■■::":'= : </Meta> ' 

<Data > US - en< / Dat a> 
' ' </Item> ' < •; • r • 

</Replace> 

<Final/> : . . < 

</SyncBody> ^ ' • « 

:/ SyncML > 



Itllfj 

. : : ::f : • :■ . 



Ir;;.: 



14.2.2 Package 2: Initialization from server to client 



< SyncML ; xml ns = ' SYNCML ': SYNCML 1 i 1 :' > 
<SyncHdr> 5 
; <VerDTD>l . !</VerDTD> 
; <VerProto>DM/l ; l</VerProto> 
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;<SessionID>l</SessionID> 
< Msg I D > 1 < / Msg I E) > 
< Source > \ 

<LocURI >ht tp : / /www . syncml . org/mgmt - server < /LocURI > 
</Source> 
<Target> 

<LocURI>IMEI:493005100592800</LocURI> 
'. < /Target > '. ' ; ; 'S' :: T::;'".;;:;-:| •; : ' ■■■M^^-'. 

<Cred> ;<!— Server credentials --> " 

<Meta> ' ' \\ '. 

: <Type xmlns=" syncml : met inf">syncml :auth-basic</Type> : 
: <Format xmlns= 1 syncml : met inf ' >b64</Format> 
;</Meta> , ; ^ '. 

t<Data>< !-- base64 formatting of userid : password - -></Data> 

</cred> -LJni^J' ■ ? -f : '■ 

</SyncHdr> ' ; ;- : - ; = ; 1: . 

< Sync Body > 
<Status> ; 

< MsgRe f > 1 < /Ms gRe fx CmdRe f > 0 < / CmdRe f > : 
p Cmd > S yn c Hd r < / Cmd > 
<CmdID>5</CmdID> 

<TargetRef >http : //www . syncml . org/mgmt - server</TargetRef > 
. <SourceRef >IMEI : 493 0051 00592 8 00</SourceRef> 
<!— Authenticated for the session --> 
. .' <Data>212</Data> 
</ S tatu S > 
i <Status> . n^fp%;:% / : 'i-3f::| : 

; <MsgRef >!</MsgRef ><CmdRef >l</CmdRef > : 
<CmdID>6</CmdID> . • i 

'. < Cmd > Al e r t < / Cmd > ',; • 

<Data>200</Data>< !-0K --> 
'■■ </Status> 

: <Status> * " ' : . .-;;?:: : : ::: 

<MsgRef >!</MsgRef xCmdRef >3</CmdRef > 
<CmdID>7</CmdID> ;^ : 

<Cmd>Replace</Cmd> 



<Data>2 0 0 < /Da ta >< ! - - OK - - > ' 



It 



</Status> ' ... ■ : ; 

< Alert > "' . ' v 

<CmdID>2</CmdID> 
<Data>1100</Data> < !— User display able notification -->]'. 
<Itemx/Item> ; 'M;^ : :||. : 

: ' ■ <Item> . ; . . • < ■ . . : ' • ; ;;, :• ' - : %<',-■ \v- . . \ ' \ \ "\ ' ■ 

<Data>Your antivirus software is being updated</Data> . 
</ltem>i ■ ' : -W^\ i 'Mi W'^'-'MM. 

' </Alert> : -• . • ' . 

< ! - - Let 1 s get the installed antivirus definition version number 
- > .: :: ■ ; H - : r :. I::.:- 

<Get> ;■'} 

<CmdID>4</CmdID> 

<Item> ' : : ;: ; ;:r.: ■ ^ ! • 

<Target> 

<LocURI>. /ant ivirus_data/versibn< /LocURI > 
< /Target > . ; - 

: </ltem> r ' : ; y ■ : ' v 

</Get> :: V-':.'- |j' ^/ . ■ ' 

<Final/> ' : ■:;;':::;v:;r ; ::: : ; : ; : : ; ;; : \- \\: ■]{ % 

:.</SyncBody> 
</ SyncML > : : ::;.! "'• • 
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14.2.3 Package 3: Client response 



<SyncML xmlns= ' SYNCML : SYNCML 1 . 1' > . 
<SyncHdr> 

<VerDTD>l . !</VerDTD> I ' ; ; 

<VerProtb>DM/l .;l</VerProto> . ' K "\ ■ 

<SessionID>l</SessionID> ' 
<MsgTD>2</MsgID> _.;;V : :: : : : 

<Target> , ; : , ; . . • ; 

s ; < LocURI >tit tp : / /www . syncml . org/mgmt - server < /LocURI > 
. </Target> 

<Source> . \ : x \-/ : k ' : • : ;-: :: : : .W:-. ^' - y 

<LocURI>IMEI :493005100592800</LocURI> 
</Source> ■' 
</SyncHdr> ; ^g:;:;: 

<SyncBody> 

<Status> . % : :i 

<MsgRef >l</MsgRef > i ;;;; 
<CmdID>l</CmdID> 
<Cmd>SyncHdr</Cmd> 
<Data>212</Data> 
< /Status > : 

i; ' <StatUS>;;i .; : • \ ; i| 

r * < Ms gRe f > 1 < / Ms gRe f > 
< CmdRe f > 2 < / CmdRe f > 
<CmdID>2</CmdID> 
<Cmd>Alert</Cmd> ; 



::'.V,::- 



<Data>2 00</Data>< !-User notification OK --> ' 
</Status> 
<Status> 

<MsgRef >l</MsgRef > 
< CmdRe f >4 < / CmdRe f > 
<CmdID>2</CmdlD> 
<Cmd>Get</Cmd> 
<TargetRef > . /antivirus_data/version</Target:Ref > 
<Data>2 00</Data>< ! - - Get OK --> 
</Status> ' 

< ! - - -Results for the Get: antivirus version number 
<Results> . ;: " *< ^ 

: <MsgRef >l</MsgRef xCmdRef >4</CmdRef > 
I -<CmdID>3</CmdID> 



<Item> 

■ ' ■ V: • • • - V 

;< Source ;> 



■ < LocURI > . / ant i virus_dat a /versions/ LocURI > 
; :</Source> \ 

<Data>antivirus-inc/20010522b/5</Data> : 

: ; . </item> r Tr- : ■ E '"K 5 ■ i ; -} : }M'- 

:: </Results> '. y. 

<Final/> : 
</SyncBody> . : ]■ ki;.:.^.^ 

</SyncML> 



• 3r : 



>*f:: 



Package 4: Continue with management operations 
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:::: 



K r :; {f£ ■.[ ■ ■ :|: I':- 



< SyncML xmlns= ' SYNCML : SYNCML 1 . 1 ' > 
<SyncHdr> 

<VerDTD>l . l</VerDTD> 
<VerProto>DM/l . l</VerPrdt6> 
<SessionID>l</SessionID> 
<MsgID>2</MsgID> 
<Target> 

<LocURI>http: //www. syncml.org /mgmt -server </LocURI> 
</Target>" 1 [ ■ 

< Source > 

< LocURI > I ME 1 :493005100592800 < /LocURI > 
j < /Source > 

* </SyncHdr> 
*' <SyhcBbdy> :: :: 
l • ^ ;.: : <Status> •••• • •• 

' <MsgRef >2</MsgRef > 
<CmdID>l</CmdID> 
<Cmd>SyncHdr</Cmd> 
<Data>212<:/Data> : 

w:- % . < /status > v : -'^- : \m : ■. m 1 :i WM, : n !: ; r : -;f .• : -\\' 

< l — Send now antivirus updates ; - : ->; : 

■ . .. :::<••; :V : ?: : s :;■ ::. . .:: 

<CmdID>2</CmdID> 
|. | m <Meta> t^ftlf | ! f;* * " / ! . 

r : < Format xmlns= "syncml : met inf! ? >b64;</ Format>- 

: <Type, xmlns= " syncml : met inf " > % \ | ■ 
t ; ! : application/antivirus-inc . virusdef 

• • r :."\ </Type> ■ .. • 

> r ■ * |/Meta> ■■ : ^ ' 

• < 1 1 em> •: • * • 

< Targe t> ^ :.; ■ '■ 

<LocURI> . /antivirus data</LocURI> 
< /Target > 

<Data><!-- Base64-coded antivirus file 
</Item> 
</Replace> ^ :.; 
<Final/> 
</SyncBody> 
^ /SyncML > ; 



.... .:; .; .• . -s •; 




14.2.5 Restart protocol iteration with Package 3: Client response 



<SyncML xmlns= ' SYNCML : SYNCML1 . 1 ' > ; ■ ; , 

<SyncHdr> : : . " " • ; : : • 

<VerDTD>l.l</VerDTD> ^ 1 ■ ' 'i 

<VerProto>DM/l: l</VerProto> i r 

<SessionID>l</SessionID>. v ; . 

<MsgID>3</MsgID> :i r : ^ ;; v .; ; - j 

<Target> ■. 

<LocURI >ht tp : //www . syncml . org/mgmt - server < /LdcURI > ' ■ 
< /Target > 

,<Source> > 

<LocURI>IMEI:493005100592800</LoeURI> 
</Source> : ; - : : i : :i Vv ; : 'MM WMW^M^± 

</SyncHdr> ' ^; ' : ; ^; j H S ^ M ; • ^ i : : ^ U n " " • V^: • ' ; : ;^ : - ; : ! ■ : : ^ : • : • • H i H : ^ • H'H N : ! ' : H T; ■ ' :■. W-'WS 

:. <SyncBody> ^'WMW::M\ MM.'^M'^M^}'-WM^. '''.\\:'\ WMMMMMMW' 

<Status> ' • 
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<MsgRef >2</MsgRef > 
<CmdID>l</CmdID> 
<Cmd>SyncHdr</Cmd> r 
<Data>200</Data> 
: </Status> :•• . •• .. . "1 : :r :: : : r 

<Status> . : . . 

<MsgRef >l</MsgRef > 
; 1 <CmdRef >2</CmdRef > : - ; ; - ! : ; : r M - 

<CmdID>2</CmdID> 
- r± : <Cmd>Replace</Cmd> ; : ' ' . r: ; ^ 

<TargetRef > . /antivirus_data</TargetRef > 
L < ! OK, antivirus update loaded- -> 

<Data>200</Data> . , 
</Status> 

< Final /> J - . : ^;-^=kU 
</SyncBody> : 'V . : : ■' . 
c/ SyncML > 



14.2.6 Package 4: Finish the protocol, no continuation 



< SyncML xmlns = ' SYNCML : SYNCML 1 . 1 ' > 
: <SyncHdr> i| : 

:| ; <VerDTD>l . !</VerDTD> 

. <VerProt6>DM/l ; l</VerProto> 
: <SessionID>l</SessionID> 

<MsgID>3</MsgID> 
;;. <Source> !.;...,•:: l&^i;;. 



< LocURI >ht t p : / /www . syncml ; ; brg/mgmt - s e rver < / LocURI > 



< /Source > 
<Target> 



: < LocURI >I ME 1:49300510 05 92 80 0< /LocURI > 
</Target> 
</SyncHdr> : 
<SyncBody> 
<Status> 
. <MsgRef >3</MsgRef > 
<CmdID>l</CmdID> 
<CmdRef >.0< /CmdRef > 
<Cmd>SyncHdr</Cmd> 
; <Data>200</Data> 
</Status> 
<Final/> 
</SyncBody> ^ 
; < / SyncML >• ■ 



If 



-•if y:[ M 
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